home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat5 / miser.z / miser
Encoding:
Text File  |  2002-10-03  |  7.3 KB  |  133 lines
  1.  
  2.  
  3.  
  4. MMMMIIIISSSSEEEERRRR((((5555))))                                                              MMMMIIIISSSSEEEERRRR((((5555))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      mmmmiiiisssseeeerrrr, bbbbaaaattttcccchhhh - The Miser Resource Manager
  10.  
  11. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.      Miser is a resource management facility with a batch process scheduling
  13.      component.  This component allows a system administrator to balance
  14.      interactive and batch load on a machine without static partitioning.
  15.      Miser provides deterministic batch scheduling associated with static
  16.      partitioning without the wasted resources that result from static
  17.      partitioning.  Idle resources are always available for use regardless of
  18.      ownership, but are reclaimed on demand as necessary.
  19.  
  20.      Miser schedules applications with known time and space requirements.  The
  21.      user level component of miser, the daemon, generates a non-conflicting
  22.      schedule of applications.  The schedule is said to be non-conflicting
  23.      because at no point in the schedule are the resources over-subscribed. An
  24.      application scheduled by miser is scheduled to begin running at a
  25.      particular point in time and then to run without preemption until the end
  26.      time has been reached.  The kernel component uses the schedule to
  27.      determine what resources an application has access to and when to
  28.      actually schedule an application to run.  The applications are said to be
  29.      scheduled in a batch fashion.
  30.  
  31.      Given a job and its resource request, a tuple of time/space, Miser
  32.      searches through a time/space pool, until it manages to find an
  33.      allocation that fits the job's requests.  A successful allocation, called
  34.      the schedule, is a tuple consisting of a start and end time and the
  35.      resources allotted to the application during the interval defined.  These
  36.      resources are guaranteed by the kernel during the schedule.
  37.  
  38.      Miser manages the time/space pool using a hierarchy of resource vectors
  39.      indexed by time, using a system-wide quantum.  All vectors are of equal
  40.      size. Each entry specifies a set of resources allocated to the vector: a
  41.      number of CPUs and an allocation of physical memory.  The system vector
  42.      defines the set of resources allocated to Miser; all other vectors
  43.      allocate their resources from the system vector.  Associated with each
  44.      vector is a vector definition (to allocate new entries as time advances),
  45.      a set of jobs scheduled against the resources of the vector, a policy
  46.      module that controls the scheduling of jobs, and miscellaneous policy-
  47.      related data.  The collection of a resource vector and its associated
  48.      code and data structures is called a Queue.
  49.  
  50.      The resource vector represents the time/space pool a Queue manages.  The
  51.      length of the resource vector defines the length of the time dimension of
  52.      the time/space pool or the duration of the time/space pool, and is
  53.      defined to be the length of the system vector.  The resource vector's
  54.      duration is not fixed in time, but rather represents how far into the
  55.      future the Queue can schedule resources.  The actual amount of space
  56.      available at any point in time is defined by the vector definition.  The
  57.      vector definition consists of a list of resource tuples.  The resource
  58.      tuples contain a start and end time, and a quantity of space.  The tuples
  59.      are ordered by their start and end times and these times are relative to
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. MMMMIIIISSSSEEEERRRR((((5555))))                                                              MMMMIIIISSSSEEEERRRR((((5555))))
  71.  
  72.  
  73.  
  74.      midnight of UTC (see gettimeofday(3B)).  The duration of the system
  75.      vector defines how far into the future relative to midnight of UTC the
  76.      last tuple's end time can be. The duration of the vector definition is
  77.      the time between time 0 and the end time of the last tuple.  If the
  78.      duration is greater than the duration of the system vector, the vector
  79.      definition is truncated.  If the vector definition is shorter, then it is
  80.      repeated.  If the duration of the vector definition does not perfectly
  81.      divide into the system vector's duration, and is smaller, then the last
  82.      repetition of the vector definition is truncated.
  83.  
  84.      Given that the origin for time is 00:00 Thursday Jan 1st, it is possible
  85.      to construct vector definitions for weeks, days or parts of days by
  86.      creating appropriate resource tuples.  Note, time zero is time zero at
  87.      GMT adjusted for timezone difference, and daylight savings.  For example,
  88.      a vector definition for a Queue that managed 10 CPUs and 1 gigabyte of
  89.      memory between 8:00pm and 4:00am and managed no resources between 4:00am
  90.      and 8:00pm would consist of two resource tuples, the first with a start
  91.      time of 00:00 hours and end time of 04:00 hours, and the second with a
  92.      start time of 20:00 hours and end time of 00:00 hours.  The actual values
  93.      of the resource vector entries, depend on the value of the current time.
  94.      So if the current time was 4:00pm, then the entries corresponding to
  95.      4:00pm through 8:00pm would reflect that there was no available space;
  96.      the entries between 8:00pm and 4:00am would reflect that the resource
  97.      vector had 10 CPUs and 1g of memory to allocate; and between 4:00am and
  98.      4:00pm there were no resource available. In other words, the value of the
  99.      0 entry of the resource vector does not correspond to time 0 of the
  100.      vector definition.  If the system vector was a week long, then the
  101.      resource vector definition would be repeated seven times. The Queue would
  102.      be able to schedule an application up to a week in advance of its
  103.      execution time.
  104.  
  105.      The policy module defines the way in which a block of time/space is
  106.      searched to satisfy the resource request made by the application.  The
  107.      two policies supplied with miser are the "default" and "repack" policy.
  108.      The "default policy is the first fit policy.  In this policy once a job
  109.      is scheduled, its start and end time remains constant.  The event of an
  110.      earlier job finishing ahead of schedule does not have any effect on the
  111.      start/end time of the future scheduled jobs.  On the other hand the
  112.      "repack" policy does as its name implies.  Each time any job ends on a
  113.      queue with a repack policy the entire job schedule is reevaluated and
  114.      updated.  When machine resources are freed due an executing job's early
  115.      termination, the repack policy will attempt to reschedule queued jobs,
  116.      pulling them ahead in time.  While repacking endeavors to maintain the
  117.      FIFO order of queued jobs, a higher priority is given to the optimal
  118.      utilization of machine resources.  The actual start and end times of a
  119.      job in a queue with a repack policy can potentially be earlier than its
  120.      initially reported start and end times.
  121.  
  122. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  123.      miser(1), miser_submit(1), miser(4), miser_jinfo(1), miser_qinfo(1),
  124.      miser_move(1), miser_reset(1).
  125.  
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.